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DEVELOPMENT AND 
ANALYSIS OF INTEGRATED 
CAISR ARCHITECTURES 


Kristin Giammarco, Michael Carlomusto, and J. D. Lock 


The U.S. Army continues to struggle with creating doctrinally correct, robust, 
consistent, and all-inclusive operational, system, and technical views based on 
the Department of Defense Architecture Framework. Having detailed, integrated, 
and up-to-date architecture views is essential to answering questions involving 
alternative system designs and operating procedures, conducting gap, overlap, 
and connectivity analyses among programs of record, and providing traceable data 
upon which to base near- and far-term acquisition decisions as the armed services 
undergo Transformation. This paper presents an overview of the Communications- 
Electronics Research, Development, and Engineering Center Command, Control, 
Communications, Computer, Intelligence, Surveillance, and Reconnaissance 
(C4ISR) methodology for developing and utilizing integrated architecture 
products for the purposes of C4ISR System-of-Systems engineering analyses. 


n support of Army leadership’s efforts to make prudent and efficient acquisition 

decisions at the system-of-systems level, the Research, Development, and 

Engineering Command (RDECOM), Communications-Electronics Research, 
Development, and Engineering Center (CERDEC) has developed a structured and 
repeatable methodology for producing and analyzing integrated Command, Control, 
Communications, Computer, Intelligence, Surveillance, and Reconnaissance (C4ISR), 
Department of Defense Architecture Framework (DoDAF) (DoDAF Architecture 
Framework Version 1, 2003) products. This integrated architecture process is a major 
component of the larger CERDEC Systems Analysis Processes and Tools (CSAP&T) 
methodology, which is a comprehensive systems engineering approach to the integration 
of architecture, Modeling and Simulation (M&S), and experimentation activities at 
CERDEC. Architecture products are used by CERDEC as vehicles for storing and 
relating essential information for analysis. They are designed to contain information 
needed for M&S, and be validated and updated based on virtual, live, and constructive 
experimentation. 
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The process described in this paper has evolved over the course of numerous studies 
done by the CERDEC Architecture and Systems Engineering Office (ASEO) for various 
Army customers, growing in fidelity and capability with each study. It is implemented 
at CERDEC using a tool called The Complete C4ISR Architectural Tool (TCAT), which 
was developed by CERDEC to meet specific M&S requirements for the architecture 
products and to improve traceability and reusability of data. The TCAT consists of 
a relational database with customized structured query language (SQL) scripts that 
present architecture information in the form of human-readable operational and system 
views and/or data files for use in other databases or spreadsheet programs, as well as 
M&S network simulation tools such as OPNET and QualNet. The TCAT database has 
been designed to be “tool agnostic,’ meaning data can be moved into and out of TCAT 
as long as acommon, specific data model is used. One of the specific data models used 15 
an Extensible Markup Language (XML) implementation of the Core Architecture Data 
Model (CADM). The CADM XML tables are used to give a common structure to data 
in the Defense Architecture Repository System (DARS), a repository through which 
data may be shared with other architecture communities. Architectures in CERDEC’s 
C4ISR database are scoped to operational, system, and technical elements in Army 
Tactical and Operational echelons to a degree of fidelity (e.g. command post, platform/ 
vehicle, staff section, dismounted soldier) that corresponds to source data availability 
and the scope of the architecture analysis being conducted. The process described in the 
following sections is currently implemented from the dismounted soldier through the 
Unit of Employment and can further scale to encompass all elements within the Global 
Information Grid (GIG) in a standardized form suitable for Joint C4ISR system-of- 
systems analyses. As such, the intent of this paper is to offer a high-level description of 
CERDEC’s integrated architecture methodology for peer evaluation of its applicability 
to Joint architectures and to solicit feedback for improvements as the requirement for 
system-of-systems analyses continues to grow in scope and fidelity. 


ARCHITECTURE DEFINED 


In an integrated architecture framework, all of the operational views (OVs), system 
views (SVs), and technical views (TVs) are connected and consistent with one another. 
The relationships between the views are what define the actual architecture, and it is the 
common data elements among the views that provide the integration. 

Table 1 summarizes the definitions (DoDAF, 2003) for each type of view. The 
all view (AV) contains high-level summary information about the architecture and 
includes references to the OVs, SVs, and TVs that make up the architecture. Because 
the architecture products are specifically developed for the purpose of conducting 
analyses, CERDEC also includes in the AV-1 the analysis questions being addressed, 
lessons learned, and tables showing OV/SV/TV traceability to the analysis questions 
and to the consumers/stakeholders, respectively. 
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TABLE 1. PRODUCTION AND ANALYSES METHODOLOGY 


View [9151 Π211116}4] 


All View (AV) Overarching aspects of an architecture that relate to all three of 
the views (e.g., Scope, content). 


Operational View (OV) Description of the tasks and activities, operational elements, 
and information exchanges required to accomplish or support a 
military operation (e.g., information flows, information exchange 
requirements [IERs)). 


Systems View (SV) Description, including graphics, of systems, and interconnections 
providing for, or supporting, warfighting functions. Associates 
physical resources and their performance attributes to the 
operational view (e.g., platforms, systems, speed of service, 
maintainability, availability, priority, security classification). 


Technical View (TV) Minimal set of rules governing the arrangement, interaction, and 
interdependence of system parts or elements, whose purpose 
is to ensure that a conformant system satisfies a specified set 
of requirements (e.g., technical standards, implementation 
conventions, standards options, rules, criteria). 


BASIC TENETS OF C4ISR ARCHITECTURE ANALYSIS 


In order to obtain consistent and meaningful analysis results, the CERDEC 
integrated architecture methodology and its implementation in the TCAT database 
are based on fundamental principles of C4ISR architecture development, as follows: 
The process used to create the architecture is an integral part of the architecture 
itself. A clearly defined and standardized process for architectural view development 
is employed for each study to ensure that a thoroughly consistent and integrated 
architecture is produced. Architecture products integrated and generated using TCAT 
are dependent upon certain practices that are observed throughout the architecture 
development process. These practices include obtaining relevant reference materials 
early on, utilizing appropriate subject matter expertise to extract required information, 
defining the relationships among key operational systems and technical data elements, 
and documenting assumptions regarding ambiguous or absent source data. Thus, the 
methodology, reference materials, and data element relationships and assumptions are 
delivered along with the architecture views for completeness and traceability. 

The basis of all architectures is the Users needs. The input of the specific operational 
unit for which the architecture is being generated is required to ensure that the operational 
views reflect the doctrinal requirements and standing operating procedures (SOPs) of 
the unit. Also required are the specifics on how that unit would operationally employ 
each fielded system in the architecture. The modeled unit’s input is a critical part of 
the methodology that ensures the validity of the architecture’s operational, system, and 
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technical views, and therefore the validity and applicability of the resulting C4ISR 
traffic model and subsequent analysis results. 

Operational, system, and technical views must be consistent. All products defining 
the same architecture are related and connected. An internally consistent architecture 
will have technical views that trace back to its system views and system views that trace 
back to its operational views. Without this interconnected traceability, a comprehensive 
identification of gaps between systems and operational functions/needs, and the 
impact of those gaps, would not be possible. A major part of accomplishing inherent 
consistency within an architecture is the early identification of source information 
needed to populate a// of the relevant framework products. This source information 
is needed to understand and establish relationships among the source data elements 
that populate the views common to an architecture. Though certain source data values 
may not be immediately available, it is important to anticipate which data fields (i.e. 
data elements, such as producer, network service, security classification, etc.) will 
be subsequently required in analysis. Knowing which fields will be necessary in the 
architecture products at the outset of a study allows more time for collecting the field 
values and reserves placeholders for these values in each relevant architecture product. 
As the values are obtained, the architecture views are populated with relevant data. 
In this way, the architecture products are used as vehicles for storing and relating the 
data needed for analysis, and any change made in one view automatically propagates 
through all affected views. 


METHODOLOGY OVERVIEW 


Before populating a single architecture product, the objectives of the analysis task 
and the questions to be addressed are determined. Once the purpose of the analysis is 
clearly established, AV products are drafted to document the scope of the architecture, 
and the data elements necessary to complete that analysis are identified. The architecture 
framework products that would contain those elements are then selected as appropriate 
vehicles for representing the data elements for analysis. 

The AV-1 (Overview and Summary Information) is updated throughout the 
development of the architecture to summarize the scope, purpose, context, tools and 
file formats, findings/recommendations, and issues/lessons learned. The AV-1 serves 
two related purposes: 1) it serves as a planning guide during architecture development, 
and 2) upon completion of the architecture, the AV-1 is revised to document conclusions 
reached from the overall architectural development experience. The AV-2 (Integrated 
Dictionary) keeps track of terms and definitions used in the architecture. This integrated 
dictionary consists of textual information in the form ofa glossary, including definitions 
of acronyms and architectural elements (e.g., activities, information flows, operational 
elements) used in the architecture. The AV-2 is an accompanying reference to the 
other products, and its value lies in the provision of unambiguous definitions among 
developers and users of the architecture. 

Once the initial information for the AVs is identified, the necessary source data 
is assembled. The source data consists of the elements necessary to populate the 
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architecture framework products undergoing analysis. Since CERDEC uses the data in 
architecture products in M&S, there is a requirement for detail not commonly captured 
in existing DoDAF products. This detail is needed in the operational and systems 
exchange requirements in order to create an adequate model of C4ISR traffic within 
an operational unit. The foundation source data elements that are used to construct the 
architecture are as follows: 


1. Force Structure Elements —Command centers, platforms/vehicles, staff sections, or 
individual soldiers that constitute the communicating operational entities within the 
organization. Also referred to as Operational Elements or Operational Entities. 


2. Operational Tasks — Doctrinal activities performed by units and staffs in support of 
a mission, extracted from the Field Manual (FM 7-15) of the Army Universal Task 
List (AUTL) and the Chairman, Joint Chiefs of Staff Manual (CJCSM 3500.04C) 
Universal Joint Task List (UJTL). Operational Tasks are also sometimes referred to 
as AUTLs/UJTLs. 


3. ReMITs (Reports, Messages, JSR, Telemetry) — This document is a catalog of 
approximately 570 specific types of C4ISR information that can be exchanged on 
the battlefield. It serves as a master pick-list of messages from the standard Variable 
Message Format (VMF), United States Message Text Formatting (USMTF), and 
Field Manual (FM 101-5-2) of U.S. Army Report and Message Formats, as well as 
Commander’s Information Requirements (CIRs) and some Future Force messages 
not yet documented elsewhere. This master list was compiled with definitions by 
CERDEC and the TRADOC Analysis Center (TRAC), and is formatted for use in 
detailed analyses. This information is also referred to as C4ISR Products or C4ISR 
Information Elements. 


4. Format Parameters — Each ReMIT has a specific perishability, cost of failure, 
precedence and security classification. ReMITs may occur in the format of data, 
imagery, voice, and/or vidstream. Each ReMIT format has certain parameters 
associated with it; such as data rate, frequency, size, duration, and speed of service. 
The values for the Format Parameters provide a quantitative value to each ReMIT. 


5. Systems — For the purposes of present CERDEC analyses, a system is the sending 
or receiving end-user application or piece of communications equipment in the 
system architecture that is resourced to and used by a force structure element in the 
operational architecture. Systems are used to communicate information ReMITs 
from producers to consumers in support of operational requirements. Systems that 
have been represented in CERDEC studies include the Army Battle Command 
System (ABCS) applications and their application servers, Voice over Internet 
Protocol (VoIP) phones, generic computers/laptops, and collaboration/VTC equip- 
ment. The ABCS includes such systems as: 


¢ Maneuver Control System — Lite (MCS-L), 
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¢ All-Source Analysis System — Lite (ASAS-L), 

¢ Global Command and Control System — Army (GCCS-A), 

e Air and Missile Defense Workstation (AMDWS), 

¢ Integrated Meteorological System (IMETS), 

¢ Digital Topographical Support System — Lite (DTSS-L), and others. 


The source data described above is used to populate architecture framework products 
that are either mission independent or mission specific. The distinction between the 
two types of products is summarized in Table 2. 

The architecture framework products associated with the study are then exported 
from the data in the TCAT database. The DoDAF views currently able to be generated 
using TCAT include: 


m OV-2 (Operational Node Connectivity Description), 
m OV-3 (Operational Information Exchange Matrix), 
ΒΞ OV-6b (Operational State Transition Description), 


m OV-6c (Operational Event-Trace Description), SV-4 (Systems Functionality 
Description), 


m SV-5 (Operational Activity to Systems Function Traceability Matrix), 


TABLE 2. FRAMEWORK PRODUCT DISTINCTIONS 


Mission-Independent C4ISR Exchanges Mission-Specific C4ISR Exchanges 


Developed to conduct general traffic load Developed to conduct analysis on a specific 
analyses (e.g., average bandwidth through mission thread (e.g., performance of the mission 
systems, into and out of operational elements) thread over a loaded network) 


Regular interval traffic used to load the network | Each exchange is associated with a step in a 
mission thread 


A frequency field captures an average rate of Each unique exchange occurs only once 
occurrence for each unique exchange. There according to its time stamp. The first 

are no time stamps, and start/end times are exchange(s) in the sequence starts when the 
arbitrary. mission thread is triggered. 


100,000s to 1,000,000s of unique exchanges 100s to 1,000s of unique exchanges may be 
may be identified identified 

Examples of traffic include common Examples of traffic include a call for fire, a 
operational picture updates, ISR updates battle update brief 
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m SV-6 (Systems Data Exchange Matrix), and 


m SV-10c (Systems Event-Trace Description). 


Products that already exist for an architecture undergoing analysis are integrated 
into the database and augmented as needed, prior to generating the higher fidelity 
equivalent products utilized in M&S. 


TRAFFIC PROFILE DEVELOPMENT 


An example of a specific type of analysis that CERDEC ASEO has conducted 
highlights the use of both mission independent and mission specific products. First, a 
unit-specific, mission independent product referred to as a traffic profile is developed. 
This product, populated based on the available source data, is used to estimate the 
offered load of background traffic on the C4ISR network being analyzed. Mission- 
specific products, referred to as mission threads, are then layered over the traffic profile 
to (among other uses described in Lindy, et al.) measure the performance of network 
services associated with the mission over the C4ISR network that is already loaded 
with background traffic. 

This process for developing the traffic profile and mission threads for an architecture 
utilizes common reference data as well as the same set of relationships established 
among that reference data. Because the source data is common, both the traffic profile 
and the mission threads are developed to the same degree of fidelity for a given 
architecture. 

The traffic profile consists of a subset of mission independent information exchanges 
between producer-consumer pairs thatis directly traceable to the operational information 
exchange requirements and is required for modeling application-level user traffic. 
It contains information such as the producing and consuming operational elements, 
ReMIT, ReMIT format (data, imagery, voice or vidstream), ReMIT attributes (data 
rate, duration, size, frequency), and the following fields not captured in the architecture 
products: 


1. Network Services — These are the delivery mechanisms used to transport ReMITs 
in the system architecture. Real-time services such as VoIP and Collaboration (e.g. 
Video Teleconferencing [VTC], whiteboarding, text chat, etc.) are identified in the 
system architecture for use in subsequent performance analyses, whereas non-real- 
time services such as Peer-to-Peer (between ABCS systems), E-mail, and Web/ 
TACWeb are identified in order to understand the network load over which the 
real-time services must perform. 


2. Network — This field identifies the physical networks that are used to transport 
the individual messages. Unclassified but Sensitive Internet Protocol Router 
Network (NIPRNET) and Secret Internet Protocol Router Network (SIPRNET) 
traffic are identified based on ReMITs and their security classifications. Joint 
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Worldwide Intelligence Communications System (JWICS) and Combat Service 
Support (CSS) traffic are identified based on ReMIT, and represent Intelligence 
and Logistics information respectively. Relationships of Systems and C4ISR 
information to specific Networks are used to analyze the load on each Network and 
explore information dissemination concepts. 


To create a traffic profile, operational, systems, and technical subject matter experts 
(SMEs) first set up source matrices, which are used to establish relationships among 
the source data elements. A matrix is set up on a spreadsheet by listing data elements of 
one kind down the first column and data elements of another kind across the first row. 
The cells of the matrix are then populated to show the relationship between two data 
elements. The following relationships among data elements constitute the principle 
matrices used by CERDEC to construct integrated architecture products, including a 
traffic profile: 


1. Operational Tasks performed during Battle Phases. 

2. Force Structure Elements performing Operational Tasks. 
3. ReMITs required to execute Operational Tasks. 

4. ReMITs exchanged by Force Structure Elements. 

5. Format Parameters associated with each ReMIT. 

6. Systems resourced to Force Structure Elements. 

7. Operational Tasks supported by Systems. 

8. ReMITs exchanged by Systems. 

9. Network Services available to Systems. 

10. Networks available to Systems. 

The matrices allow relationships among data elements to be assigned ina consolidated 
manner, and are the key to producing completely consistent architecture views. Note 
that some matrices relate system architecture data to operational architecture data, so 
that resulting OVs and SVs are consistent with one another. (Technical View matrices 
are being integrated in 2005.) Furthermore, the matrices are set up to be modular, 
thus enabling architectural updates to be made in a matter of hours or days rather than 
weeks or months, allowing the effects of small changes to be studied before network 


configuration decisions are made. 
The following is a brief description of each of the matrices listed above: 


312 


Operational Tasks performed during Battle Phases. This matrix captures the 
operational tasks (i.e., AUTLs and/or UJTLs) that are performed during each phase 
of battle (Objective Force: Unit of Employment Concept, 7 August, 2002): Entry, 
Shape, Decisive, and Transition (e.g., Conduct Landing Zone Operations during 
Entry phase). 


Force Structure Elements performing Operational Tasks. This matrix captures 
each operational task performed by each force structure element according to the 
doctrinal requirements of the unit being analyzed (e.g., 3[D/UE-x/DIV HO/DTAC 
CP1/ADA' performs Conduct Landing Zone Operations). 


ReMITs required to execute Operational Tasks. This matrix captures all C4ISR 
information (Reports, Messages, ISR, and Telemetry), known in short as ReMITs, 
needed for or generated by the completion of each operational task. Some tasks 
call for ReMITs being generated (produced) as output of the task, and some tasks 
call for ReMITs being required (consumed) as input to the task. This matrix just 
captures the doctrinal association of the ReMITs with each task, not who specifically 
is producing and consuming the information (e.g., an JNTSUM (Intelligence 
Summary) is required to execute Conduct Landing Zone Operations). 


ReMITs exchanged by Force Structure Elements. This matrix captures each ReMIT 
produced and consumed by each force structure element. This defines a general 
flow of information that is based on the unit’s standing operating procedures 
(SOPs) (i.e., “business practices”) that is independent of mission or scenario. This 
matrix provides the average C4ISR production and consumption at each element 
in the unit for use in subsequent bandwidth requirements analyses. This matrix is 
automatically cross-referenced with both the “Force Structure Elements performing 
Operational Tasks” and the “ReMITs required to execute Operational Tasks” 
doctrinal matrices to ensure the ReMIT flows defined in this SOP matrix support 
the operational tasks performed by each element in the unit. If any inconsistencies 
are found, the matrices are revisited and the necessary corrections are made before 
generating the final traffic profile that is used in analysis. 


Format Parameters associated with each ReM/IT. Each ReMIT may occur in one 
or more formats: data, imagery, voice, or vidstream. Every potential format of 
each ReMIT has a set of parameters assigned to it: frequency of occurrence (per 
hour) for each battle phase, security classification, precedence, criticality, and 
perishability. In addition, size (in kilobytes, before system and network overhead) 
is populated for the non-streaming formats of data and imagery, and duration (in 
seconds) and data rate (in kbps) are populated for the streaming formats of voice 
and vidstream. These format parameters quantify each ReMIT so that the C4ISR 
exchanges can later be simulated. 


Systems resourced to Force Structure Elements. This relationship is extracted 
directly from the unit-specific System Architecture (SA) produced by the Program 
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Executive Office Command, Control and Communications Tactical/Office of the 
Chief Engineer Knowledge Engineering Information Laboratory (PEO C3T OCE 
KEIL). CERDEC ASEO and OCE KEIL collaborate to load the TCAT database 
with data from the SA database so that updates to the KEIL system architecture 
are reflected in the CERDEC analyses. This collaboration allows for a consistent, 
timely, and configuration-controlled update to the traffic profile upon which the 
analysis is based and will eventually be expanded to allow a near real time update 
to both the data and the analysis results. 


7. Operational Tasks supported by Systems. This set of mappings is used to help 
narrow the assignment of a system for an information exchange. It includes all 
the operational tasks that a particular system would be used to support. This 
information is provided by individual system subject matter experts. 


8. ReMITs exchanged by Systems. This set of mappings is used to assign systems to 
an information exchange. It ensures that an information exchange is assigned to 
systems that are capable of exchanging it. 


9. Network Services available to Systems. This is a set of mappings that are combined 
with programming logic to determine the network service used in the sending and 
the receiving of a ReMIT. Network Services include VoIP, Collaboration, Tactical 
Web (TACWEB), E-mail, Peer-to-Peer, and others. A different set of network 
services can be defined based on the needs of the particular analysis of the given 
system architecture. 


10. Networks available to Systems. The assignment of networks is based on the system 
architecture source data and some programmed logic. Network examples are SIPR, 
NIPR, JWICS and CSS. 


Once the basic matrices above are completed, SQL scripts are executed to generate 
the traffic profile and populate all the architecture products at once with the appropriate 
information required for each view. The traffic profile contains the user-generated 
C4ISR exchange requirements that need to occur no matter what the scenario is or 
where the unit is deployed. Once this baseline is constructed, customization can begin 
for various types of mission specific analyses. 


MISSION THREAD DEVELOPMENT 


Architecture products containing mission-specific data can be layered over the traffic 
profile for various types of performance analyses. These views contain sequenced 
events among operational elements of the force structure and their systems. 

The mission-specific products are built using the same source data as used in the 
traffic profile, and include additional information such as thread name, sequence 
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number, and a description for each task in the thread. For an in-depth description of the 
process used to generate mission-specific products (Lindy, et al.). 


PREPARING THE ARCHITECTURE FOR MODELING & SIMULATION 


Upon final compilation of the architecture data for a given analysis, the data mined 
from the TCAT database (e.g., traffic profile, mission threads) are formatted for more 
specific M&S excursions to test the behavior of the network under various operational 
and technical circumstances. 

The architecture products and the traffic profile alone do not capture the physical 
path of each exchange. They only capture the C4ISR exchanges that are associated with 
the end user (i.e., user traffic from producer to consumer). Internal network exchanges 
(i.e., network traffic among intermediary devices* needed to accomplish the end user 
exchanges must be added to account for overhead associated with dynamic network 
management traffic. Describing these internal exchanges in the architecture also helps 
to quantify subsequent analyses of information dissemination schemes. 


The mission-specific products are built using the same source 
data as used in the traffic profile, and include additional 
information such as thread name, sequence number, and a 
description for each task in the thread. 


The completed traffic profile serves as the basis for deriving the service flows and 
the application control profiles used for the bandwidth and performance analyses, 
respectively. In generating these derivative input files, first the server dispositions/ 
locations for each service are incorporated into each data set. Secondly, the traffic 
is aggregated based on sender/receiver pair and service. Lastly, the data is translated 
into the formats required for driving the flow analysis tool and the OPNET simulation 
models. 

At this point, the M&S phase of the analysis is entered. Briefly described, the data 
contained in the traffic model contributes to architectural analysis enabled by M&S 
analysis. Combined withmodels ofcommunications assets andnetwork services, analysis 
questions such as optimum server placement to minimize bandwidth requirements, 
performance of real-time applications (e.g., collaboration tools and VoIP) during busy 
times on the network, and suitability of a proposed Active Directory architecture are 
addressed in flow analysis and/or simulation runs, where parameters associated with 
network and service configurations can be varied. These analysis examples merely 
touch the surface of questions that can be and are being addressed using the CERDEC 
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CSAP&T process. Furthermore, new questions continuously arise as new issues 
are encountered both prior to unit deployment and in the field. The structured and 
repeatable process described above is an essential component to CERDEC’s capability 
of adapting to changing architecture configurations, and its ability to quickly respond 
to analysis questions in time to be of help to the end user, the Warfighter. 


The repeatability of the methodology and the 
experience gained in implementing if, as well as the 
availability of the large body of previous work are 
key factors in the success of enabling quick response 
analyses required by an Army at war. 


For each analysis that employs the CSAP&T methodology, the body of work created 
in previous analyses is leveraged and built upon. Volumes of documentation are 
associated with each analysis activity, and include the data sets, reference materials/ 
source data, assumptions, methodology description and study overview. Time- 
sensitive analysis results are distributed to stakeholders at regular intervals throughout 
the analysis as technical bulletins, which often spur new questions and a revisit to 
the analysis to conduct additional excursions and explore possible alternatives. The 
repeatability of the methodology and the experience gained in implementing it, as well 
as the availability of the large body of previous work are key factors in the success of 
enabling quick response analyses required by an Army at war. 


SUMMARY 


The uniqueness of the methodology described in this article is that it provides a 
means to adapt to rapidly changing doctrine, systems, and parameters with efficiency 
and fidelity. Since much of the data is first created independently of mission, the same 
data may be reused, customized, and applied to various operational scenarios, missions, 
and conditions. All architecture data—regardless of its operational, system, or technical 
nature—is designated and stored in one common database. As such, consistency among 
the architecture products is guaranteed. Data common to more than one view is stored 
only once and referenced as many times as necessary. Furthermore, the work required 
to update the architecture is minimized. As the design evolves, the source data and the 
mappings in the matrices change. Whenever this happens, the modular nature of the 
matrices allows the affected portions of the architecture to be updated, and the SQL 
scripts are re-run so that all the views are updated simultaneously. Any changes to data 
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in one view propagate through to all affected views. This approach has reduced the 
turn-around time on updating highly detailed architecture products and corresponding 
analysis results, from months to days or even hours, allowing “what if” studies never 
before possible. 

Since it is now possible to create an integrated architecture formatted for analysis in 
less time using the above methodology, and through efficiencies gained by collaboration 
with organizations such as the KEIL, the CERDEC has applied its resources towards 
conducting the C4ISR systems engineering analyses needed to make recommendations 
regarding the architecture to DA leadership, PEOs and PMs, as well as the end customer/ 
user: the unit itself. Having developed a structured, repeatable approach to integrating 
and developing architectures as well as the foundational skill set to conduct and repeat 
various types of analyses in 2004, the ASEO continues to evolve its process to a level 
of efficiency such that analysis results can be obtained and used to support traceable 
recommendations prior to costly hardware development, software development, 
production and testing takes place. 

The CERDEC CSAP&T methodology is embedded in doctrine, customizable to 
scenario, geography, systems and technology, able to represent Current Force, Modular 
Force, or Future Force task organizations and able to produce architectures with fidelity 
and resolution down to the dismounted soldier and up through Joint, Coalition and 
Strategic domains. Ultimately, it is our goal to have all OVs, SVs and TVs (as well 
as relevant data not currently captured in any view) in a single automated systems 
engineering process designed for system-of-systems analysis, whose data elements are 
commonly defined across the Army community and beyond. 
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END NOTES 


1. This is an example of a shorthand description that hierarchically represents a 
force structure element, and is read from right to left: The Air Defense Artillery 
(ADA) element (which could be a section, platoon, battery or staff liaison officer) 
in Division Tactical Command Post 1 (DTAC CP1) in Division Headquarters (DIV 
HQ) in Unit of Employment-x (UE-x) in the 3rd Infantry Division (910). 


2. Intermediary devices include servers, routers, switches, and other network 


management devices comprising the actual network topology. These exchanges 
are accounted for separately in the traffic and simulation models. 
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DoDAF -- 
CERDEC — 


C4ISR — 


SoS — 
RDECOM — 
CSAP&T — 
M&S — 
ASEO -- 
TCAT — 
SQL -- 
XML — 
CADM -- 
DARS -- 
UE- 
GIG -- 
OV - 

SV - 
TV- 

AV - 
SOP -- 
FM — 
CJCSM — 
AUTL -- 
USTL — 
ReMIT — 


VME — 
USMTE — 
CIR — 
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ACRONYM KEY 
(IN ORDER OF APPEARANCE) 


Department of Defense Architecture Framework 


Communications-Electronics Research, Development, and 
Engineering Center 


Command, Control, Communications, Computer, Intelligence, 
Surveillance, and Reconnaissance 


System-of-Systems 

Research, Development, and Engineering Command 
CERDEC Systems Analysis Processes and Tools 
Modeling and Simulation 

Architecture and Systems Engineering Office 
The Complete C4ISR Architectural Tool 
Structured Query Language 

Extensible Markup Language 

Core Architecture Data Model 

Defense Architecture Repository System 
Unit of Employment 

Global Information Grid 

Operational View 

Systems View 

Technical View 

All View 

Standing Operating Procedure 

Field Manual 

Chairman, Joint Chiefs of Staff Manual 
Army Universal Task List 

Universal Joint Task List 


Reports, Messages, Intelligence/Surveillance/Reconnaisance, 
Telemetry 


Variable Message Format 
United States Message Text Formatting 


Commandert’s Information Requirement 


TRADOC — 
TRAC — 
ABCS — 

VoIP — 
VTC - 
MCS-L — 
ASAS-L — 
GCCS-A — 
AMDWS -- 
IMETS — 
DTSS-L — 
TACWeb — 
NIPRNET — 
SIPRNET — 
JWICS — 
CSS - 
SMEs — 
310 — 

UE-x — 
DIV HQ - 
DTAC CP1 — 
ADA - 

SA -- 

PEO - 

C3T — 

OCE — 
KEIL — 

DA -- 

PM — 


Training and Doctrine Command 


Training and Doctrine Command Analysis Center 
Army Battle Command System 

Voice over Internet Protocol 

Video Teleconference 

Maneuver Control System — Lite 

All-Source Analysis System — Lite 

Global Command and Control System — Army 
Air and Missile Defense Workstation 

Integrated Meteorological System 

Digital Topographical Support System — Lite 
Tactical Web 

Unclassified but Sensitive Internet Protocol Router Network 
Secret Internet Protocol Router Network 

Joint Worldwide Intelligence Communications System 
Combat Service Support 

Subject Matter Experts 

3rd Infantry Division 

Unit of Employment-x 

Division Headquarters 

Division Tactical Command Post 1 

Air Defense Artillery 

System Architecture 

Program Executive Office 

Command, Control, and Communications Tactical 
Office of the Chief Engineer 

Knowledge Engineering Information Laboratory 
Department of the Army 


Program Manager 
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